1. Field of the Invention
The present invention relates to a wireless communications network. In particular, the present invention discloses a method for performing lossless relocation of a serving radio network subsystem.
2. Description of the Prior Art
Please refer to FIG. 1. FIG. 1 is a block diagram of a wireless communications network 10. The wireless communications network 10 comprises a plurality of radio network subsystems (RNSs) 20 in communications with a core network (CN) 30. Each RNS 20 comprises one radio network controller (RNC) 22 that is in communications with a plurality of node Bs 24. Each node B 24 is a transceiver, which is adapted to send and receive wireless signals. In particular, the wireless communications network 10 assigns a mobile unit 40 to a particular RNS 20, which is then termed the serving RNS (SRNS) 20s of the mobile unit 40. Data destined for the mobile unit 40 is sent by the CN 30 to the SRNS 20s. This data is in the form of service data units (SDUs) 28 that are held by the RNC 22 of the SRNS 20s pending transmittal by one of the Node Bs 24. The RNC 22 selects a node B 24 that is best able to accurately transmit the SDUs 28 to the mobile unit 40. Such a selection will depend, for example, upon the location of the mobile unit 40 within the domain of the SRNS 20s. The mobile unit 40 broadcasts SDUs 48 to the wireless communications network 10, which are then picked up by the SRNS 20s and forwarded to the CN 30. Occasionally, the mobile unit 40 may move close to the domain of another RNS 20, which is termed a drift RNS (DRNS) 20d. A node B 24 of the DRNS 20d may pick up one or more of the SDUs 48 transmitted by the mobile unit 40. The RNC 22 of the DRNS 20d forwards the received SDUs 48 to the SRNS 20s. The SRNS 20s then forwards these received SDUs 48 to the CN 30. Consequently, all communications between the mobile unit 40 and the CN 30 must pass through the SRNS 20s. 
Please refer to FIG. 2 in conjunction with FIG. 1. FIG. 2 is a block diagram of the RNC 22 of the SRNS 20s. Communications between the mobile unit 40 and the RNC 22 are effected through a multi-layered communications protocol that has a packet data convergence protocol (PDCP) layer 22p in communications with an upper layer 22u and a lower layer 22L. The PDCP layer 22p receives a plurality of SDUs 28 from the upper layer 22u. Each SDU 28 includes a header 28h and data 28d. The primary purpose of the SDU 28 is to carry the data 28d to a destination indicated by the header 28h. The header 28h is analogous to an Internet protocol (IP) header. The header 28h may carry a lot of information that is redundant or repeated through the other SDU headers 28h in the other SDUs 28. One purpose of the PDCP layer 22p is to compresses the headers 28h so as to maximize bandwidth. This compression is performed by way of a header compressor/decompressor 22c. The header compressor/decompressor accepts an SDU 28 and generates a PDCP protocol data unit (PDCP PDU) 29. A PDCP PDU 29 includes a PDCP header 29h and data 29d. The data 29d includes compressed header data 29x that is generated by the header compressor/decompressor 22c according to the header 28h. Each PDCP PDU 29s is incrementally assigned a 16-bit sequence number (SN) 29s by the PDCP layer 22p. That is, each sequentially successive PDCP PDU 29 is assigned an incrementally higher SN 29s. For example, a first PDCP PDU 29 may be assigned an SN 29s of 62. A second PDCP PDU 29 immediately after the first PDCP PDU 29 would thus be assigned an SN 29s of 63, and so on. The SNs 29s are not actually a part of the PDCP PDUs 29, but are internally maintained by the PDCP layer 22p. The PDCP PDUs 29 are then delivered to the lower layer 22L for transmission. As there is a one-to-one correspondence between PDCP PDUs 29 and SDUs 28, and as each PDCP PDU 29 has an assigned SN 29s, each corresponding SDU 28 also has an associated SN 29s. That is, the SNs 29s are associated with both the PDCP PDUs 29 and the corresponding SDUs 28. Since bandwidth is to be maximized by the compression of the headers 28h, each PDCP PDU 29 should, ideally, be smaller in size than its corresponding SDU 28. To ensure that this is indeed the case, the PDCP header 29h should be kept as small as possible. The type of header compression used for the header compressor/decompressor 22c will depend upon the format of the headers 28h. As an example, though, if the headers 28h are IP headers, then the compression performed could conform to the IP industry standard RFC 2507.
Similarly, PDCP PDUs 27 received from the lower layer 22L (i.e., originating from the mobile unit 40) are fed into the header compressor/decompressor 22c to generate the corresponding SDUs 48. The SDUs 48 so generated are then delivered to the upper layer 22u. Each PDCP PDU 27 has a 16-bit SN 27s assigned to the PDCP PDU 27 by the PDCP layer 22p, in a manner that is analogous to the SNs 29s. These SNs 27s are also associated with the corresponding SDUs 48.
As the mobile unit 40 moves closer towards the domain of the DRNS 20d, more and more SDUs 48 are received and forwarded by the DRNS 20d. Eventually, a decision is made by the wireless network 10 to place the mobile unit 40 under the DRNS 20d, and a transfer process is enacted. This process is termed a SRNS relocation procedure, and should be lossless. Lossless means that no SDUs 28, 48 are lost during the relocation procedure. Please refer to FIG. 3 in conjunction with FIGS. 1 and 2. FIG. 3 is a block diagram of the mobile unit 40 undergoing a lossless SRNS relocation procedure. The DRNS 20d becomes a target RNS (TRNS) 20t. After completion of the relocation procedure, the TRNS 20t will serve as the new SRNS 20s for the mobile unit 40. In order for the TRNS 20t to properly take up its job as the new SRNS 20s for the mobile unit 40, the current SRNS 20s must forward key information to the TRNS 20t. Please refer to FIG. 4 in conjunction with FIGS. 2 and 3. FIG. 4 is a message sequence chart for the prior art lossless SRNS relocation procedure. The SRNS 20s sends forwarding information 50 to the TRNS 20t. This forwarding information includes a downlink sending sequence number (DL Send_SN) 52, an uplink receiving sequence number (UL Receive_SN) 54, and all unconfirmed SDUs 28. The multi-layered communications protocol used by both the SRNS 20s and the mobile unit 40 enables the mobile unit 40 to confirm those PDCP PDUs 29 transmitted by the SRNS 20s that are successfully received by the mobile unit 40. Any PDCP PDUs 29 not explicitly confirmed as received by the mobile unit 40 are termed unconfirmed PDCP PDUs 29. As there is a one-to-one correspondence between SDUs 28 and PDCP PDUs 29, an unconfirmed PDCP PDU 29 means that there is a corresponding unconfirmed SDU 28. These unconfirmed SDUs 28 are forwarded by the SRNS 20s to the TRNS 20t. The DL Send_SN 52 is the value of the SN 29s associated with the sequentially earliest unconfirmed PDCP PDU 29. As the SNs 29s are not explicitly carried in the SDUs 28, this enables the TRNS 20t to properly associate an SN 29s for the corresponding PDCP PDU 29 of each forwarded SDU 28. The UL Receive_SN 54 is the value of the SN 27s associated with the PDCP PDU 27 that the SRNS 20s next expects to receive from the mobile unit 40. This enables the TRNS 20t to properly associate an SN 27s for each subsequently received PDCP PDU 27 from the mobile unit 40. The TRNS 20t sends the UL Receive SN 54 to the mobile unit 40. From this, the mobile unit 40 can determine which packets 48 to begin sending to the TRNS 20s under its guise as the new SRNS 20s. The mobile unit 40 sends a downlink receiving sequence number (DL Receive_SN) 58 to the TRNS. The DL Receive_SN 58 holds the value of the SN 29s of the next PDCP PDU 29 that the mobile unit 40 is expecting to receive from the TRNS 20t. From this, the TRNS 20t can learn which of the forwarded unconfirmed SDUs 28 to begin sending to the mobile unit 40. Consider, as an example, a situation in which the SRNS 20s has sent PDCP PDUs 29 to the mobile unit 40 having associated SNs 29s running from 0 to 99. We may further assume that, of these 100 PDCP PDUs 29 sent, only those with SNs 29s running from 0 to 50 were confirmed by the mobile unit 40. Consequently, there are unconfirmed PDCP PDUs 29 with SNs 29s running from 51 to 99, each of which has a corresponding unconfirmed SDU 28. Also, the SRNS 20s has received 200 PDCP PDUs 27 from the mobile unit 40, with SNs 27s running from 0 to 199. In the prior art SRNS relocation procedure, the SDUs 28 with associated SNs 29s running from 51 to 99 are forwarded by the SRNS 20s to the TRNS 20t. The DL Send_SN 52 would have a value of 51, and the UL Receive_SN 54 would have a value of 200. The DL Receive_SN 58 will hold a value that is between 51 and 100, depending on how many of the unconfirmed PDCP PDUs 29 were actually received by the mobile unit 40, but not yet confirmed. If, for example, the DL Receive_SN 58 holds a value of 90, then the TRNS 20t knows that it may discard the forwarded SDUs 28 that have associated SNs 29s that run from 51 to 89, and will begin transmitting those forwarded SDUs 28 with associated SNs 29s that are from 90 and above. Although it should not happen, it is possible that the DL Receive_SN 58 will either be sequentially before the DL Send_SN 52 or sequentially after the SN 29s associated with the sequentially last forwarded SDU 28. Such an occurrence means that the SNs 29s and/or 27s maintained by the RNC 22 of the SRNS 20s are out of synchronization with corresponding SNs maintained by the mobile unit 40. A re-synchronization procedure is thus enacted by the TRNS 20t. During the re-synchronization procedure, the TRNS 20t transmits PDCP PDUs 29 that explicitly contain their associated SNs 29s in their PDCP headers 29h, beginning with the PDCP PDU 29 corresponding with the sequentially earliest forwarded SDU 28. Once the mobile unit 40 has confirmed one of these PDCP PDUs 29, the TRNS 20t stops including the SNs 29s in the PDCP headers 29h. Including the SN 29s in the PDCP header 29h is not desired, as it increases the size of the PDCP header 29h, but it does enable the mobile phone to synchronize its internally maintained SNs with those of the SRNS 20s. 
However, there may be times that a re-synchronization procedure should be performed that are not detectable by the prior art SRNS relocation procedure. As initial conditions, consider the case in which the SRNS 20s has 30 unconfirmed SDUs 28: the first 20 of these unconfirmed SDUs 28 have been transmitted, but not confirmed, while the last 10 have not yet been transmitted, and so could not possibly have been confirmed. During the SRNS relocation procedure, all 30 of these unconfirmed SDUs 28 are forwarded to the TRNS 20t. If it is assumed that the first of these unconfirmed SDUs 28 as an associated SN 29s of 101, then DL Send_SN 52 will have a value of 101. Four cases arise, depending upon the value of DL Receive_SN 58:
Case 1: DL Receive_SN 58 is less than 101. The re-synchronization procedure is performed, as the mobile unit 40 should not indicate that it is expecting to receive an SDU 28 that is sequentially before one that has already been confirmed by the mobile unit 40. All SDUs 28 are received and confirmed in sequential order.
Case 2: DL Receive_SN 58 is between 101 and 121. This is the typical case, and the mobile unit is confirming reception of some or all of the first 20 unconfirmed SDUs 28 that were transmitted by the SRNS 20s. No re-synchronization process is performed, so that no SNs 29s are explicitly sent in the PDCP PDUs 29 sent by the TRNS 20t. 
Case 3: DL Receive_SN 58 exceeds 131. In this case, the mobile unit is indicating that it has already received SDUs 28 that the SRNS 20s never had, which were never forwarded, and so which could not possibly have been transmitted. Re-synchronization is performed. Finally, and most importantly,
Case 4: DL Receive_SN 58 is between 122 and 131. In this case, a re-synchronization procedure should be performed, as the SRNS 20s never actually transmitted the SDUs 28 with associated SNs 29s between 122 and 131. However, the TRNS 20t has no way of knowing this, for insufficient information is provided by the SRNS 20s. This will lead to data loss, as the forwarded SDUs 28 that have associated SNs 29s before DL Receive_SN are discarded by the TRNS 20t. 
It is therefore a primary objective of this invention to provide lossless relocation for a new serving radio network subsystem (SRNS) that can detect occurrences in which re-synchronization between the mobile unit and the SRNS needs to be performed to prevent loss of data.
Briefly summarized, the preferred embodiment of the present invention discloses a method for performing lossless relocation of a serving radio network subsystem (SRNS) in a wireless communications network. Radio network subsystems (RNSs) are provided that are in communications with a core network (CN). One of the RNSs is an SRNS, and another RNS is a target RNS (TRNS). The SRNS is in wireless communications with a mobile unit to provide service data units (SDUs) from the CN to the mobile unit. The SRNS associates a sequence number (SN) with each of the SDUs, and the mobile unit is capable of confirming to the SRNS SDUs received from the SRNS. Forwarding information is provided by SRNS to the TRNS. The forwarding information includes SDUs unconfirmed as received by the mobile unit, a first SN that is the SN of the sequentially last unconfirmed SDU actually transmitted to the mobile unit by the SRNS, and a second SN that is the SN of the sequentially earliest unconfirmed SDU. Finally, the TRNS is made the new SRNS for the mobile unit.
It is an advantage of the present invention that by providing the first SN, the TRNS can determine if the mobile unit is responding to the lossless SRNS procedure with an SN that is sequentially too far ahead, and thus more accurately determine when a re-synchronization process should be performed.
These and other objectives of the present invention will no doubt become obvious to those of ordinary skill in the art after reading the following detailed description of the preferred embodiment, which is illustrated in the various figures and drawings.